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(54) Einleitung einer elektronischen Zahlungstransaktion 



(57) Die Erfindung betrifft ein Verfahren zur Einlei- 
tung einer elektronischen Zahlungstransaktion. Ein Fil- 
ter Fl empfangt eine Zahlungsanforderung 300 und mo- 
difiziert sie durch Hinzufugen einer Transaktionskenn- 
zeichnung. Er sendet die modif izierte Zahlungsanforde- 
rung 301 an einen Transaktionsserver WS, sowie eine 
Zahlungsanforderungsinformation 302, welche die 
Transaktionskennzeichnung enthalt, an ein Kommuni- 
kationsendgerat MS. Der Transaktionsserver WS emp- 
fangt die modifizierte Zahlungsanforderung 301 , sowie 
eine Zahlungsinitialisierung 303, welche eine weitere 



Transaktionskennzeichnung enthalt, von dem Kommu- 
nikationsendgeratMS. Der Transaktionsserver WS ver- 
gleicht die Transaktionskennzeichnungen der modifi- 
zierten Zahlungsanforderung 301 und der Zahlungsin- 
itialisierung 303 und fuhrt die Zahlungstransaktion 304 
durch, wenn die Transaktionskennzeichnungen uber- 
einstimmen. Die Erfindung betrifft weiterhin einen ent- 
sprechenden Filter Fl und Transaktionsserver WS, ein 
Verfahren zur Initialisierung des Filters Fl, sowie ein 
Computerprogramm zur Einleitung einer elektronischen 
Zahlungstransaktion und Initialisierung des Filters Fl. 



FIG. 3 




Printed by Jouve, 75001 PARIS {FR) 



1 



EP1 182 625 A1 



Beschreibung 
Gebiet der Erf indung 

[0001] Die vorliegende Erfindung betrifft den elektro- 
nischen Zahlungsverkehr. Insbesondere betrifft die Er- 
findung ein Verfahren und ein Computerprogramm zur 
Einleitung einer eiektronischen Zahlungstransaktion, ei- 
nen Filter und einen Transaktionsserver eines Kommu- 
nikationssystems mittels derer die elektronische Zah- 
lungstransaktion eingeleitet bzw. durchgefuhrt wird, so- 
wie ein Verfahren und Computerprogramm zur Initiali- 
sierung des Filters. 

Hintergrund der Erfindung 

[0002] Die steigende Verbreitung mobiler Kommuni- 
kationsmittel zur Sprach- und Datenubertragung weckt 
den Bedarf nach mobilen Diensten im Bereich des eiek- 
tronischen Geschaftsverkehrs, d.h. Diensten wie elek- 
tronischem Bezahlen, Ticketbestellungen Oder Home- 
Banking mittels mobiler Kommunikationsmittel. Dazu 
konnen die Zahlungssysteme in Mobil kommunikations- 
systeme integriert werden. Derartige Mobilkommunika- 
tionssysteme sind beispielsweise ein Global System for 
Mobile Communication (GSM), ein GSM System, wel- 
ches einen General Packet Radio Service (GPRS) bie- 
tet, ein Packet Personal Digital Cellular (PPDC) System, 
ein Wideband Code Division Multiple Access (WCDMA) 
System, ein Universal Mobile Telecommunication Sy- 
stem (UMTS), ein Bluetooth™ System, ein Digital Eu- 
ropean Cordless Telecommunications (DECT) System 
Oder drahtlose Local Area Network (LAN)- bzw. draht- 
lose Asynchronous Transfer Mode (ATM) Systeme. 
[0003] Ein bekanntes Protokoll fur elektronische Zah- 
lungsvorgange ist das Secure Electronic Transaction 
(SET™) Protokoll, welches einem Kreditkarteninhaber 
mittels eines Endgerates, beispielsweise eines Perso- 
nal Computers (PC), ein sicheres elektronisches Be- 
zahlen uber ein offenes Netz, beispielsweise uber das 
Internet, ermoglicht. Die von SET™ verwendeten Ver- 
schlusselungsalgorithmen stellen hohe Anforderungen 
an Prozessorleistung und Speicherplatz des Endgera- 
tes. Mobile Kommunikationsmittel, beispielsweise Mo- 
biltelefone, konnen diese Anforderungen vielfach nicht 
erfullen. SET™ ist daher in einer fur den PC vorgese- 
henen Implementierung als Protokoll fur elektronische 
Zahlungsvorgange mittels mobiler Kommunikations- 
endgerate nicht geeignet. 

[0004] Zwei Konzepte zu einer Implementierung des ' 
SET™ Protokolls zur eiektronischen Bezahlung mittels 
mobiler Kommunikationsendgerate werden in dem Arti- 
kel 'Adaptation of the SET Protocol to Mobile Networks 
and to the Wireless Application Protocol', Proceedings 
of European Wireless '99, 1999, S. 193-198, VDE-Ver- i 
lag Berlin, von K. Wrona und G. Zavagli vorgeschlagen. 
In einem Konzept werden Zahlungstransaktionen von 
einem SET™ Wallet Server, der beispielsweise Be- 



standteil eines Mobilkommunikationssystems ist, stell- 
vertretend fur das mobile Kommunikationsendgerat 
durchgefuhrt. Dabei enthaltder SET™ Wallet Server die 
gesamte SET™-Funktionalitat. Die zur Verschlusse- 

5 lung vom SET Protokoll verwendeten Schlussel, ein 6f- 
fentlicher und ein privater Schlussel des Kunden, d.h. 
des Benutzersdes Kommunikationsendgerates, sind im 
SET™ Wallet Server gespeichert. 
[0005] In einem weiteren Konzept wird ein Split 

10 SET™ Server vorgeschlagen. Ebenso wie der SET™ 
Wallet Server fuhrt der Split SET™ Server Zahlungs- 
transaktionen mittels des SET™ Protokolls stellvertre- 
tend fur das mobile Kommunikationsendgerat aus. Der 
Split SET™ Server enthalt dazu den offentlichen 

is Schlussel des Kunden. Der private Schlussel des Kun- 
den wird in dem mobilen Kommunikationsendgerat, bei- 
spielsweise in einer Subscriber Identity Module (SIM) 
Karte des Endgerates oder einer anderen Smart-Card 
gespeichert. 

[0006] Zur Kommunikation mit dem SET™ Server 
und einem Server eines Handlers werden das Hypertext 
Transfer Protocol HTTP und die Verwendung von Java 
vorgeschlagen. Zur Kommunikation mit einem Wireless 
Application Protocol (WAP) Telefon ubersetzt ein WAP 
?5 Proxy Gateway zwischen dem HTTP Protokoll und dem 
WAP Protokoll. 

[0007] In beiden beschriebenen Konzepten werden 
Zahlungstransaktionen durch Zahlungsanforderungen 
ausgelost, welche von einem Server eines Handlers an 

f 0 das Kommunikationsendgerat des Kunden gesendet 
werden. Das Kommunikationsendgerat muB zum eiek- 
tronischen Bezahlen die jeweilige Zahlungsanforderung 
verarbeiten konnen, unabhangig von der GroBe der 
Nachricht, ihrem Inhalt Oder dem verwendeten Ubertra- 

s gungsprotokoll. Dies stellt einen erheblichen Aufwand 
und Kostenfaktor dar, weil dazu im Kommunikations- 
endgerat ausreichende Ressourcen, d.h. Verarbei- 
tungs- und Speicherkapazitat vorgehalten werden mus- 
sen. 

f [0008] Die Verwendung eines WAP-Proxy Gateways 
lost dieses Problem nicht. Wenn beispielsweise eine 
Zahlungsanforderung, welche als HTTP Nachricht von 
einem Server des Handlers abgeschickt werden kann, 
nach der Ubersetzung in das WML-Format die zulassi- 

~> ge WML-SeitengroBe uberschreitet, ist sie im Kommu- 
nikationsendgerat nicht mehr darstellbar. 
[0009] In dem Artikel 'Mobile Chip Electronic Com- 
merce: Enabling Credit Card Payment For Mobile De- 
vices', Proceedings of eBiz2000, Juni 2000, Singapur, 

> von M. Schuba und K. Wrona wird das Mobile Chip Elec- 
tronic Commerce Konzept vorgestellt, welches die Cli- 
ent-Funktionalitat des SET™-Protokolls in eine Client- 
Fun ktionalitat in einem mobilen Kommunikationsendge- 
rat, sowie in eine Serverfun ktionalitat in einem Mobile 
Chip Electronic Commerce Server aufteilt. Der elektro- 
nische Bezahlvorgang wird durch eine Zahlungsanfor- 
derung, die der Server des Handlers an das mobile End- 
gerat des Kunden sendet, eingeleitet. Die Zahlungsan- 
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forderung enthalt den zu zahlenden Betrag, eine Wah- 
rungsangabe, Angaben uber Kreditkarten, die von dem 
Handler akzeptiert werden, eine Adresse des Handlers, 
sowie Details der aufgegebenen Bestellung. Das mobile 
Kommunikationsendgerat sendet daraufhin eine Zah- 5 
lungsinitialisierung an den Mobile Chip Electronic Com- 
merce Server. Die Zahlungsinitialisierung enthalt neben 
Daten aus der Zahlungsanforderung einen Kreditkar- 
tentyp, ein Ablaufdatum der Kreditkarte, sowie eine 
Kontonummer. Nach Erhalt der Zahlungsinitialisierung 
fuhrt der Mobile Chip Electronic Commerce Server ei- 
nen zur Zahlung mittels des SET™-Protokolls erforder- 
lichen Nachrichtenaustausch mitdem Server des Hand- 
lers, sowie einen Nachrichtenaustausch mit dem Kom- 
munikationsendgerat zur Authentifizierung und zur Zah- 
lungsbestatigung durch. 

[001 0] Ebenso wie bei dem SET™ Wallet Server Kon- 
zept und dem Split SET™ Server Konzept ist bei dem 
Mobile Chip Electronic Commerce Konzept von Nach- 
teil, daB das Kommunikationsendgerat zum Einleiten 
der elektronischen Zahlungstransaktion die Zahlungs- 
anforderung unabhangig von ihrer GroBe, ihrem Inhalt 
Oder dem verwendeten Obertragungsprotokoll verarbei- 
ten unddeshalbdie notwendigen Ressourcen bereithal- 
ten muB. 

[0011] Alternativ ist es denkbar, daB der Server des 
Handlers die Fahigkeiten des Kommunikationsendge- 
rates kennt und die Zahlungsanforderung hinsichtlich 
ihrer GroBe, ihres Inhaltes und des verwendeten Uber- 
tragungsprotokolls entsprechenden anpaBt. Dies erfor- 
dert jedoch einen erheblichen Aufwand, beispielsweise 
hinsichtlich der erforderlichen Signalisierung der vor- 
handenen Verarbeitungskapazitaten. Die Leistungsfa- 
higkeit des Zahlungssystems ist zudem begrenzt, wenn 
hinsichtlich der Kommunikationsendgerate die Kompa- 
tibilitat mit alten Oder leistungsschwachen Geraten ge- 
wahrleistet wird. 

Aufgabe der Erfindung 

[001 2] Es ist die Aufgabe der vorliegenden Erfindung, 
den elektronischen Zahlungsverkehr, insbesondere mit- 
tels mobiler Kommunikationsendgerate, derart zu ver- 
bessern, daB eine zuverlassige Zahlungsabwicklung 
unabhangig von der Leistungsfahigkeit des Endgerates 
gewahrleistet ist. 

Zusammenfassung der Erfindung 

[0013] Die Aufgabe wird erfindungsgemaB gelost 
durch die Lehre der unabhangigen Anspruche 1 , 7, 9, 
14 und 16. 

[0014] Anspruch 1 beschreibt ein Verfahren zur Ein- 
leitung einer elektronischen Zahlungstransaktion, An- 
spruch 9 einen Filter eines Kommunikationssystems 
und Anspruch 14 einen Transaktionsserver. 
[0015] An einer Einleitung einer elektronischen Zah- 
lungstransaktion sind ein Server eines Handlers, ein 



Kommunikationsendgerat eines Kunden, ein Transakti- 
onsserver, sowie ein Filter beteiligt. Jeder Anbieter von 
Waren Oder Dienstleistungen kann ein Handler sein. 
Der Filter ist Bestandteil eines Kommunikationssy- 
stems. Das Kommunikationssystem erlaubt eine Kom- 
munikation zwischen dem Server des Handlers, dem 
Kommunikationsendgerat und dem Transaktionsserver. 
Vorzugsweise erfolgtdie gesamte Kommunikation uber 
den Filter. Der Filter hat u.a. die Aufgabe, bestimmte 
Nachrichten, welche die elektronische Zahlungstrans- 
aktion betreffen, an zugeordnete Empfanger weiterzu- 
leiten. 

[0016] Der Transaktionsserver, der beispielsweise 
ein SET™ Wallet Server, ein Split SET™ Server oder 
ein Mobile Chip Electronic Commerce Server sein kann, 
verfugt uber eine Software, beispielsweise gemaB des 
SET™ Protokolls, zur Durchfuhrung einer elektroni- 
schen Zahlungstransaktion zu Lasten des Kunden. Der 
Transaktionsserver ubernimmt vorteilhafterweise re- 
chen- und speicherplatzintensive Verfahrensschritte 
der Zahlungstransaktion. Das Kommunikationsendge- 
rat wird nicht mit der Verarbeitung dieser Verfahrens- 
schritte belastet. Die Zahlungstransaktion, welche der 
Server des Handlers anfordert, wird lediglich durch das 
Kommunikationsendgerat, beispielsweise ein Mobilte- 
lefon oder eine elektronische Geldborse, des Kunden 
bestatigt. 

[0017] Im folgenden wird der NachrichtenfluB zur Ein- 
leitung einer elektronischen Zahlungstransaktion naher 
erlautert. Der Server des Handlers fordert mittels einer 
Zahlungsanforderung eine elektronische Zahlung an. 
Die Anforderung erfoigt, beispielsweise nachdem ein 
Kunde mittels des Kommunikationsendgerates eine Be- 
stellung uber das Internet aufgegeben hat. Neben ei- 
nem zu zahlenden Betrag, einer Wahrungsangabe, An- 
gaben uber von dem Handler akzeptierte Kreditkarten, 
und einer Adresse des Handlers kann die Zahlungsan- 
forderung Details der aufgegebenen Bestellung enthal- 
ten, beispielsweise eine Liste der bestellten Waren oder 
Dienstleistungen. Auch ein ausformulierter Kaufvertrag 
oder die Allgemeinen Geschaftsbedingungen des 
Handlers konnen Bestandteil der Zahlungsaufforderung 
sein. Vorteilhafterweise gibt es keine GroBenbeschran- 
kung fur die Zahlungsanforderung. In einer Ausgestal- 
tung der Erfindung ist die Zahlungsanforderung an den 
Filter adressiert, d.h. die Filteradresse ist in diesem Fall 
dem Server des Handlers bekannt. Die Filteradresse 
kann dem Server des Handlers beispielsweise im Rah- 
men des Bestellvorgangs durch den Kunden mitgeteilt 
worden sein, oder sie kann als Bestandteil von Kunden- 
daten beim Server des Handlers gespeichert sein. 
[0018] Der Filter empfangt und modifiziert die Zah- 
lungsanforderung durch Hinzufiigen einer Transakti- 
onskennzeichnung, die beispielsweise ein numerischer 
Wert sein kann, und sendet die modifizierte Zahlungs- 
anforderung an den Transaktionsserver. Die Adresse 
des Transaktionsservers kann test im Filter gespeichert 
sein. Der Filter sendet eine Zahlungsanforderungsinfor- 
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mation, welche die Transaktionskennzeichnung enthalt, 
an das Kommunikationsendgerat des Kunden. Die 
Adresse des Kommunikationsendgerates kennt der Fil- 
ter beispielsweise aus der Zahlungsanforderung. 
[0019] Vorteilhafterweise wird die Zahlungsanforde- 
rung, die beispielsweise bei einem umfangreichen Ein- 
kauf viele Daten enthalten kann, nicht an das Kommu- 
nikationsendgerat des Kunden, welches hinsichtlich der 
Verarbeitungskapazitatdes Prozessors und hinsichtlich 
des verfugbaren Speicherplatzes besch ran kt sein kann, 
gesendet, sondern an den Transaktionsserver, der uber 
eine ausreichende Prozessorleistung und uber genu- 
gend Speicherkapazitat zur Verarbeitung groBer Zah- 
lungsanforderungen verfugt. Weiterhin ist es vorteilhaft, 
daB die Luftschnittstelle des Mobilfunksystems zum 
Kommunikationsendgerat nicht durch die Ubertragung 
der Zahlungsanforderung, die eine groBe Datenmenge 
enthalt, belastet wird. Verzogerungszeiten, welche 
durch eine Ubertragung der Zahlungsanforderung bei 
einem System mit geringer Ubertragungsrate auf der 
Luftschnittstelle auftreten und welche die Akzeptanz 
elektronischer Zahlungsvorgange auf der Kundenseite 
verringern, werden vermieden. 
[0020] Die Zahlungsanforderungsinformation, wel- 
che der Filter an das Kommunikationsendgerat sendet, 
enthalt bevorzugt eine wesentlich geringere Datenmen- 
ge als die Zahlungsanforderung. Im einfachsten Fall be- 
steht die Zahlungsanforderungsinformation aus der 
Transaktionskennzeichnung. Die Zahlungsanforde- 
rungsinformation kann auch von Mobilfunksystemen mit 
geringer Datenrate auf der Luftschnittstelle schnell an 
das Kommunikationsendgerat des Kunden ubertragen 
werden. Die geringe GroBe der Zahlungsanforderungs- 
information macht ihre Ubertragung hinsichtlich des ver- 
wendeten Ubertragungsmechanismus flexibel. Bei- 
spielsweise kann sie mittels einer leitungsvermittelten 
Oder einer paketorientierten Datenverbindung, mittels 
des Short Message Service (SMS) Oder mittels des Un- 
structured Supplementary Service Data (USSD) uber- 
tragen werden. Als weiteres Protokoll, welches auf die- 
sen oder anderen Transportprotokollen aufsetzt, kann 
vorteilhafterweise WAP verwendet werden. 
[0021] Nach dem Empfang der Zahlungsanforde- 
rungsinformation sendet das Kommunikationsendgerat 
eine Zahlungsinitialisierung an den Transak+ionsserver, 
dessen Adresse im Kommunikationsendgerat gespei- 
chert sein oder durch den Kunden eingegeben werden 
kann. Das Senden der Zahlungsinitialisierung kann au- 
tomatisch nach dem Empfang der Zahlungsanforde- 
rungsinformation erfolgen, beispielsweise im Rahmen 
einer WAP-Session, die von dem Kommunikationsend- 
gerat zu dem Transaktionsserver aufgebaut wird. Die 
Zahlungsinitialisierung stellt eine Bestatigung fur den 
Transaktionsserver dar, den Zahlungsvorgang durchzu- 
fuhren. Sie enthalt die Transaktionskennzeichnung der 
Zahlungsanforderungsinformation. Die Zahlungsinitiali- 
sierung kann mittels der gleichen Mechanismen uber- 
tragen werden wie die Zahlungsanforderungsinformati- 



on. 

[0022] Der Transaktionsserver empfangt von dem Fil- 
ter die modifizierte Zahlungsanforderung, sowie von 
dem Kommunikationsendgerat die Zahlungsinitialisie- 

5 rung. Sobald diese beiden Nachrichten vorliegen, ver- 
gleicht er ihre Transaktionskennzeichnungen. Wenn die 
Transaktionskennzeichnungen ubereinstimmen, fuhrt 
der Transaktionsserver die Zahlungstransaktion durch, 
beispielsweise mittels der Mechanismen des SET™ 

io Protokolls. Durch den Vergleich der Transaktionskenn- 
zeichnungen kann der Transaktionsserver auf einfache 
Art sicherstellen, daB die Zahlung durch den Kunden 
autorisiert, d.h. freigegeben ist. An der Durchfuhrung 
der Zahlung kann neben dem Transaktionsserver und 

is dem Server des Handlers ein weiterer Server, beispiels- 
weise auch ein Bankserver eines Kreditinstitutes, betei- 
ligt sein. 

[0023] Der Filter verfugt uber eine Eingangsschnitt- 
stelle zum Empfang der Zahlungsanforderung, uber ei- 

20 ne Ausgangsschnittstelle zum Senden der modifizierten 
Zahlungsanforderung, sowie der Zahlungsanforde- 
rungsinformation, und uber eine Rechnereinheit zur 
Identifizierung und zur Modifikation der Zahlungsanfor- 
derung. Die Rechnereinheit kann eine Hardware, bei- 

25 spielsweise ein Prozessor, oder eine Software, bei- 
spielsweise eine virtuelle Maschine, sein. 
[0024] Der Transaktionsserver verfugt uber eine Ein- 
gangsschnittstelle zum Empfang der modifizierten Zah- 
lungsanforderung und der Zahlungsinitialisierung, uber 

30 eine Recheneinheit zum Vergleichen der Transaktions- 
kennzeichnungen der modifizierten Zahlungsanforde- 
rung und der Zahlungsinitialisierung, sowie uber eine 
Ausgabeschnittstelle, uber welche die Recheneinheit 
die Zahlungstransaktion durchfuhrt, wenn die Transak- 

35 tionskennzeichnungen ubereinstimmen. ZweckmaBig 
kann die Recheneinheit uber einen Speicher verfugen, 
welcher eine Nachricht, d.h. die modifizierte Zahlungs- 
anforderung oder die Zahlungsinitialisierung, beispiels- 
weise die zuerst empfangene Nachricht, Oder beide 

40 Nachrichten speichern kann. 

[0025] Die Erfindung erlaubt die Verwendung komple- 
xer und sicherer Protokolle, beispielsweise des SET™ 
Protokolls, zur Durchfuhrung von elektronischen Zah- 
lungstransaktionen, die hohe Anforderungen an Re- 

45 chenkapazitat und Speicherplatz stellen, fur mobile 
Kommunikationsendgerate mit begrenzten Ressour- 
cen. 

[0026] Weiterhin ist die Erfindung vorteilhaft, wenn 
die Kommunikation zwischen dem Server des Handlers 

so und dem Kommunikationsendgerat mittels einer Kom- 
munikations-Session, beispielsweise einer WAP-Sessi- 
on, erfolgt, welche keinen anderen Session-Teilnehmer, 
beispielsweise den Transaktionsserver, als Kommuni- 
kationspartner zulaBt, oder welche durch eine Nachricht 

55 eines anderen Kommunikationspartner, beispielsweise 
des Transaktionsserver, unterbrochen oder beendet 
wird. Die Erfindung erlaubt die Beibehaltung der Kom- 
munikations-Session zwischen dem Server des Hand- 
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lers und dem Kommunikationsendgerat auch wahrend 
der Durchfuhrung der elektronischen Zahlungstransak- 
tion mittels des Transaktionsservers, da dieser von dem 
Filter hinsichtlich des Nachrichtenftusses in die beste- 
hende Kommunikationssession integriert wird. 
[0027] Der unabhangige Anspruch 7 beschreibt eine 
Initialisierung eines Filters eines Kommunikationssy- 
stems. Der Filter benotigt eine Adresse eines Transak- 
tionsservers, um empfangene Zahlungsanforderungen 
weiterleiten zu konnen. Dazu empfangt der Transakti- 
onsservereine Filterinitialisierungsanforderung, diebei- 
spielsweise von einem Kommunikationsendgerat ge- 
sendet wird, und die den Transaktionsserver veranlaBt, 
eine Filterinitialisierungsnachricht, welche seine Adres- 
se enthalt, an den Filter zu senden. Die Filterinitialisie- 
rungsnachricht wird von dem Filter des Kommunikati- 
onssystems empfangen und die enthaltene Adresse im 
Filter gespeichert 

[0028] Die Initialisierung des Filters ist flexibel, d.h. 
sie kann zu beliebigen Zeitpunkten, beispjelsweise vor 
jedem Senden einer Zahlungsanforderung Oder bei ei- 
nem ersten oder bei jedem Anmelden eines Kommuni- 
kationsendgerates im Kommunikationssystem, erfol- 
gen. Sie erlaubt eine einfache Anderung der Adresse 
des Transaktionsservers. Die Filterinitialisierung ist be- 
sonders vorteilhaft, wenn mehrere Transaktionsserver 
zur Durchfuhrung von Zahlungstransaktionen zur Ver- 
fugung stehen. Die Filterinitialisierungsnachricht kann 
dann den fur einen bestimmten Kunden zustandigen 
Transaktionsserver angeben, d.h. beispielsweise den- 
jenigen Transaktionsserver, der ein entsprechendes 
Kundenkonto verwaltet. 

[0029] Vorteilhafterweise kann die Erfindung als 
Computerprogramm realisiert werden. Dies erlaubt die 
Verwendung der Erfindung in Endgeraten, ohne daB 
Anderungen an der Hardware erforderlich sind. Weiter- 
hin erlaubt das Computerprogramm im Rahmen von 
Herstellungsprozessen die einfache und kostengunsti- 
ge Durchfuhrung von Tests und Simulationen. 
[0030] Weitere vorteilhafte Ausfuhrungsformen und 
Verbesserungen der Erfindung sind den abhangigen 
Anspruchen 2 bis 6, 8, 10 bis 13, 15 und 17 zu entneh- 
men. 

[0031] GemaB Anspruch 2 ist die Transaktionskenn- 
zeichnung eine ZufallszahL GemaB Anspruch 1 0 erfolgt 
die Ermittlung der Zufallszahl durch einen Zufallszah- 
lengenerator beispielsweise mittels einer mathemati- 
schen Zufallsfunktion, des Filters. Der Zufallscharakter 
der Transaktionskennzeichnung kann Manipulationen 
unbefugter Dritter, beispielsweise mittels gefalschter 
Zahlungsinitialisierungen, verhindern. In einer weiteren 
Ausgestaltung der Erfindung ist die ermittelte Transak- 
tionskennzeichnung einmalig, zumindest in einem be- 
stimmten Zeitraum. Dies kann beispielsweise sicherge- 
stellt werden, indem der Filter alle in dem Zeitraum er- 
mittelten Transaktionskennzeichnungen speichert. 
Nach der Ermittlung einer weiteren Transaktionskenn- 
zeichnung stellt der Filter vor einer Verwendung dieser 



weiteren Transaktionskennzeichnung mittels einer 
Speicherabfrage sicher, daB die weitere Transaktions- 
kennzeichnung keiner der abgespeicherten Transakti- 
onskennzeichnungen entspricht. Die Einmaligkeit der 

5 verwendeten Transaktionskennzeichnung schutzt vor 
Verwechslungen bei der durch den Transaktionsserver 
durchgefuhrten Zuordnung von modifizierter Zahlungs- 
anforderung und Zahlungsinitialisierung. 
[0032] GemaB Anspruch 3 ist die Zahlungsanforde- 

10 rung fur das Kommunikationsendgerat bestimmt, d.h. 
sie ist an das Kommunikationsendgerat adressiert. Der 
Filter, der sich im Obertragungsweg zwischen dem Ser- 
ver des Handlers und dem Kommunikationsendgerat 
befindet, erkennt bei einer Untersuchung einer empfan- 

15 genen Nachricht anhand eines ersten Bezeichners, der 
den Nachrichtentyp kennzeichnet, beispielsweise bei 
Verwendung eines HTML-Nachrichtenformates anhand 
des Content-Typs, z.B. 'application/payment-request', 
daB es sich um eine Zahlungsanforderung handelt. Der 

20 Filter fangt diese Nachricht ab, d.h. sie wird dem Kom- 
munikationsendgerat nicht zugestellt, sondern wie unter 
Anspruch 1 angegeben weiterverarbeitet. Dadurch ist 
der Filter transparent, d.h. unsichtbar, fiir den Server 
des Handlers. Der Server des Handlers muB die Zah- 

25 lungsanforderung nicht an den Filter adressieren und 
benotigt daher keine Adresse des Filters. Daher kann 
ein Betreiber des Kommunikationssystems, beispiels- 
weise zur Wartung des Systems, Rekonfigurationen wie 
einen Austausch des Filters Oder eine Anderung der Fil- 

30 teradresse einfach und unbemerkt von dem Server des 
Handlers vornehmen. 

[0033] GemaB Anspruch 11 erfolgen die Uberprii- 
fung, ob die Zahlungsanforderung den ersten Bezeich- 
ner enthalt, und das Abfangen mittels der Rechenein- 

35 he it des Filters. 

[0034] Die Ausgestaltungen, die in den Anspruchen 
4, 12 und 15 beschrieben sind, gestatten eine vorteil- 
hafte Initialisierung des Filters. 
[0035] GemaB der Anspruche5, 8 und 13 wird die Fil- 

40 terinitialisierungsnachricht von dem Filter mittels eines 
Bezeichners erkannt und abgefangen. Der Bezeichner 
kann beispielsweise bei der Verwendung des HT- 
TP-Nachrichtenformates ein Content-Typ, z.B. 'applica- 
tion/filter-initiation', sein. Vorteilhafterweise wird die Fil- 

45 teradresse dadurch zur Einleitung der Filterinitialisie- 
rung nicht benotigt. Zur Adressierung der Filterinitiali- 
sierungsnachricht kann eine beliebige Adresse verwen- 
det werden, wenn alle von dem Transaktionsserver ge- 
sendeten Nachrichten uber den Filter des Kommunika- 

50 tionssystems geleitet werden. Beispielsweise kann die 
Filterinitialisierungsnachricht an das Kommunikations- 
endgerat adressiert werden. 

[0036] GemaB Anspruch 6 und Anspruch 15 sendet 
der Transaktionsserver nach einem Empfang einer Fil- 
55 terinitialisierungsanforderung, die von dem Kommuni- 
kationsendgerat geschickt wird, eine entsprechende Fil- 
terinitialisierung an den Filter. Die Filterinitialisierungs- 
anforderung enthalt im einfachsten Fall eine Kennzeich- 
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nung, die den Transaktionsserver zum Absenden der 
Filterinitialisierung veranlaBt. Die Kennzeichnung kann 
beispielsweise ein Content-Typ sein, z.B. 'application/ 
filterinit-request'. Vorteilhafterweise ist der Filter nicht 
sichtbar fur das Kommunikationsendgerat. Diese Art 
der Filterinitialisierung dient der Sicherheit gegen Mani- 
pulationsversuche Dritter. Der Filter kann beispielswei- 
se so eingestellt werden, daB er keine Initialisierungs- 
nachrichten von Kommunikationsendgeraten, sondern 
nur von bestimmten Transaktionsservern annimmt. 
[0037] GemaB Anspruch 17 ist das Computerpro- 
gramm auf einem computerlesbaren Medium gespei- 
chert. Dies ermoglicht, beispielsweise bei der Verwen- 
dung von Disketten Oder CD-Roms eine einfache Porta- 
bilitat des Computerprogramms, und somit den einfa- 
chen Einsatz der Erfindung in verschiedenen Geraten, 
wie beispielsweise auf Testsystemen, Simulationssy- 
stemen Oder Maschinen zur Endgeratefertigung. 
[0038] Im folgenden wird die Erfindung anhand von 
Ausfuhrungsbeispielen und anhand der Figuren naher 
erlautert. 

Kurzbeschreibung der Figuren 

[0039] Folgende Figuren zeigen: 

Fig. 1 ein System fur elektronische Zahlungstrans- 
aktionen, 

Fig. 2 ein weiteres System fur elektronische Zah- 
lungstransaktionen, 

Fig. 3 einen NachrichtenfluB zwischen Elementen 
eines Systems fur elektronische Zahlungs- 
transaktionen zur Einleitung einer Zahlungs- 
transaktion, 

Fig. 4 einen NachrichtenfluB zur Initialisierung eines 
Filters eines Systems fur elektronische Zah- 
lungstransaktionen. 

Beschreibung der Ausfuhrungsbeispiele 

[0040] Fig. 1 zeigt in einer vereinfachten Darstellung 
ein System fur elektronische Zahlungstransaktionen. Es 
besteht aus einem Server CP eines Handlers, einem Fil- 
ter Fl, einem Transaktionsserver WS und einem Kom- 
munikationsendgerat MS. Der Filter Fl ist mit alien ge- 
zeigten Komponenten logisch verbunden. Der gesamte 
Nachrichtenverkehr zwischen dem Server CP des 
Handlers und dem Kommunikationsendgerat MS erfolgt 
im angegebenen Ausfuhrungsbeispiel uber den Filter 
Fl. 

[0041] Das Kommunikationsendgerat MS ist vorzugs- 
weise ein mobiles Endgerat, beispielsweise ein Mobil- 
telefon, vorzugsweise ein WAP-Telefon, ein Laptop Oder 
ein Personal Digital Assistent PDA. Der Filter Fl ist Be- 
standteil eines Kommunikationssystems, beispielswei- 
se eines GSM-, GPRS-, PPDC-, WCDMA-, UMTS-, 
Bluetooth™-, DECT-, eines drahtlosen LAN- oder eines 
drahtlose ATM Systems. Die Kommunikation zwischen 



dem Kommunikationsendgerat und dem Filter erfolgt 
uber eine in der Figur nicht gezeigte Infrastruktur, bei- 
spielsweise uber Basisstationen und Vermittlungsstel- 
len, des Kommunikationssystems. Der Filter Fl, der Ser- 
5 ver CP des Handlers und der Transaktionsserver WS 
konnen jeweils Bestandteil eines paketvermittelnden 
Netzes, beispielsweise des Internet, sein. Alternativ 
konnen der Server CP des Handlers Oder der Transak- 
tionsserver WS mit dem Filter Fl uber eine Selbstwahl- 
10 verbindung oder uber eine Standleitung verbunden 
sein. Der Filter Fl und der Transaktionsserver konnen 
in einer weiteren Ausfuhrungsform in einem Knoten des 
Kommunikationssystems zusammengefaBt sein. Beide 
konnen durch ein gemeinsames Softwareprogramm 
15 kontrolliert werden. 

[0042] Der Server des Handlers CP ist vorzugsweise 
ein Internetserver, der auf HTML-oder WML-Seiten das 
Einkaufen von Waren oder Dienstleistungen anbietet. 
Eine Software im Kommunikationsendgerat MS, bei- 

20 spielsweise ein HTML-Betrachter, erlaubt dem Kunden 
die Auswahl der gewunschten Guter und eine entspre- 
chende Bestellung. Sowohl Kundendaten als auch die 
Software konnen auf einer SIM-Karte des Kommunika- 
tionsendgerates untergebracht sein. 

25 [0043] Nach einer Bestellung erfolgt die Bezahiung 
durch eine Zahlungstransaktion, die von dem Transak- 
tionsserver WS durchgefuhrt wird. Dazu kann der 
Transaktionsserver WS eine Datenbank mit einem ent- 
sprechenden Kundenkonto enthalten. Der Filter Fl er- 

30 mdglicht es u.a., fur das Kommunikationsendgerat be- 
stimmte Nachrichten an den Transaktionsserver umzu- 
leiten. 

[0044] Die Zahlungstransaktion wird vorzugsweise 
mittels des SET™ Protokolls durchgefuhrt, welches je- 

35 weils im Transaktionsserver WS und sowie im Server 
CP des Handlers implementiert ist. Die Server WS, CP 
konnen beispielsweise die zur Verwendung des SET™ 
Protokolls erforderlichen Verschlusselungs- und Au- 
thentifizierungsmaBnahmen durchfuhren. Die elektroni- 

^0 sche Bezahiung kann abhangig vom verwendeten Pro- 
tokoll weitere, in der Figur nicht gezeigte, Knoten invol- 
vieren, beispielsweise einen Server oder ein Gateway 
eines Kreditinstitutes. 

[0045] Fig. 2 zeigt in einer vereinfachten Darstellung 
45 ein weiteres System fur elektronische Zahlungstransak- 
tionen. Im folgenden werden nur Komponenten und 
Funktionen erklart, die hinsichtlich Fig. 1 nicht erlautert 
wurden. Das System enthalt zusatzlich zwischen dem 
Kommunikationsendgerat MS und dem Filter Fl ein Ga- 
so teway GW, welches zur Protokollkonvertierung dient. 
Vorzugsweise erfolgt die Kommunikation zwischen dem 
Server CP des Handlers, dem Filter Fl, dem Transakti- 
onsserver WS und dem Gateway GW mittels des HT- 
TP-Protokolls. Das Kommunikationsendgerat verwen- 
55 det dagegen beispielsweise WAP als hoheres Ubertra- 
gungsprotokoll. Das Gateway GW fuhrt die Uberset- 
zung zwischen den Protokollen durch. 
[0046] Das in Fig. 2 gezeigte System fur elektronische 
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Zahlungstransaktionen enthalt weiterhin mehrere 
Transaktionsserver WS, WS1, WS2. Beispielsweise 
konnen mehrere Kreditkarten institute jeweils einen ei- 
genen Transaktionsserver WS, WS1, WS2 betreiben. 
Zahlungstransaktionen eines Kunden, der uber ver- 
schiedene Kreditkarten verfugt, konnen in Abhangigkeit 
von der jeweils zur Bezahlung ausgewahlten Kreditkar- 
te mittels unterschiedlicher Transaktionsserver WS, 
WS1, WS2 ausgefuhrt werden. Die Verwendung meh- 
rerer Transaktionsserver kann auch zur Lastverteilung 
Oder Kapazitatserweiterung dienen. 
[0047] Fig. 3 zeigt einen Nachrichtenaustausch zwi- 
schen Komponenten eines Systems fur elektronische 
Zahlungstransaktionen. Dargestellt istder Informations- 
fluB zwischen einem Server CP eines Handlers, einem 
Filter Fl, einem Transaktionsserver WS und einem Kom- 
munikationsendgerat MS. Nachdem beispielsweise ein 
Bestellvorgang eines Kunden bei einem Handler erfolgt 
ist, wird eine elektronische Zahlungstransaktion einge- 
leitet. Dazu sendet der Server CP des Handlers eine 
Zahlungsanforderung 300 an das Kommunikationsend- 
gerat MS des Kunden. Die Zahlungsanforderung enthalt 
beispielsweise den zu zahlenden Rechnungsbetrag, ei- 
ne Wahrungsangabe, Angaben uber akzeptierte Kredit- 
karten oder eine Kontoverbindung des Handlers, eine 
Adresse des Handlers, sowie Details der aufgegebenen 
Bestellung. Weiterhin enthalt die Zahlungsanforderung 
300 einen ersten Bezeichner, der sie als eine Nachricht 
vom Typ 'Zahlungsanforderung' kennzeichnet, bei- 
spielsweise bei der Verwendung des HTTP Protokolls 
einen Content-Typ 'application/payment- request'. Der 
Filter Fl untersucht alle empfangenen Nachrichten dar- 
aufhin, ob sie einen solchen Bezeichner enthaiten. 
Nachrichten, die diesen Bezeichner enthaiten, werden 
nicht an den ursprunglich vorgesehenen Adressaten 
weitergeleitet, sondern abgefangen. Die in Fig. 3 ange- 
gebene Zahlungsanforderung 300 enthalt diesen ersten 
Bezeichner, und sie wird deshalb nicht an das Kommu- 
nikationsendgerat MS weitergeleitet. 
[0048] Statt dessen modifiziert der Filter Fl die Zah- 
lungsanforderung 300 durch das Hinzufugen einer 
Transaktionskennzeichnung. Der Filter sendet die mo- 
difizierte Zahlungsanforderung 301 an den Transakti- 
onsserver WS. Die Adresse des Transaktionsservers 
WS ist entweder fest im Filter abgespeichert, beispiels- 
weise in einem ROM-Speicher, oder sie wird dem Filter 
im Rahmen einer Filterinitiaiisierung, wie spater noch 
beschrieben wird, mitgeteilt. 

[0049] In einer weiteren Ausfuhrungsform wird die zur 
Modifikation der Zahlungsanforderung zu verwendende 
Transaktionskennzeichnung dem Filter Fl von dem 
Kommunikationsendgerat MS, beispielsweise nach ei- 
ner erfolgten Bestellung von Waren oder Dienstleistun- 
gen bei dem Server CP des Handlers, mitgeteilt. Damit 
kann sichergestellt werden, daf3 der Filter Zahlungsan- 
forderungen des Servers des Handlers nur dann bear- 
beitet, wenn er die vom Kommunikationsendgerat ver- 
gebene Transaktionskennzeichnung vorliegen hat. 



Durch dieses Sicherheitsmerkmal kann sichergestellt 
werden, daB der Filter keine unerwarteten Zahlungsan- 
forderungen bearbeitet. Weiterhin kann der mitgeteilten 
Transaktionskennzeichnung eine bestimmte Gultig- 
s keitsdauer zugewiesen werden, urn zu verhindern, daB 
sie, falls der Server CP des Handlers keine Zahlungs- 
anforderung sendet, falschlicherweise fur eine Einlei- 
tung einer spateren Zahlungstransaktion verwendet 
wird. 

w [0050] Der Filter Fl sendet weiterhin eine Zahlungs- 
anforderungsinformation 302 an das Kommunikations- 
endgerat MS. Die Zahlungsanforderungsinformation 
302 enthalt im wesentlichen die gleiche Transaktions- 
kennzeichnung, mittels derer die Zahlungsanforderung 

15 300 modifiziert worden ist. Das Kommunikationsendge- 
rat reagiert, automatisch oder auf Veranlassung des 
Kunden, mit dem Absenden einer Zahlungsinitialisie- 
rung 303 an den Transaktionsserver WS. Die Zahlungs- 
initialisierung 303 enthalt die Transaktionsnummer, wel- 

20 che in der Zahlungsanforderungsinformation 301 ent- 
haiten war. 

[0051] Der Transaktionsserver vergleicht fur die emp- 
fangene modifizierte Zahlungsinformation 301 und fur 
die empfangene Zahlungsinitialisierung 302 deren 

25 Transaktionskennzeichnungen. Eine Ubereinstimmung 
entspricht in dem gezeigten Ausf uhrungsbeispiels einer 
Bestatigung der Zahlung, und der Transaktionsserver 
WS fuhrt durch eine Kommunikation mit dem Server CP 
des Handlers die Zahlungstransaktion 304 durch. In Ab- 

30 hangigkeit von dem verwendeten Protokoll zur Durch- 
f uhrung der elektronischen Zahlung kann die dargestell- 
te Zahlungstransaktion 304 eine Vielzahl von Nachrich- 
ten umfassen, welche zwischen dem Transaktionsser- 
ver WS und dem Server CP des Handlers ausgetauscht 

35 werden, oder auch eine weitere Instanz, beispielsweise 
einen Server eines Kreditinstitutes, einbeziehen. 
[0052] Fig. 4 zeigt einen NachrichtenfluB zur Initiali- 
sierung eines Filters Fl eines Systems fur elektronische 
Zahlungstransaktionen. Filterinitiaiisierung bedeutet, 

40 daB dem Filter Fl eine Adresse eines Empfangers, bei- 
spielsweise eines Transaktionsservers WS, mitgeteilt 
wird, welcher stellvertretend fur ein bestimmtes Kom- 
munikationsendgerat MS oder einen bestimmten Kun- 
den einen oder mehrere bestimmte Nachrichtentypen, 

45 beispielsweise eine Zahlungsanforderung empfangt 
und verarbeitet, d. h. beispielsweise eine elektronische 
Zahlungstransaktion durchfuhrt. In einer weiteren Aus- 
gestaltung der Erfindung wird an den Filter bei der In- 
itialisierung (ibertragen, fur welche Nachrichtentypen 

so dies gelten soil. Weiterhin konnen dem Filter bei der In- 
itialisierung Verarbeitungsregeln fur Nachrichten eines 
bestimmten Typs gesendet werden, beispielsweise zur 
Modifikation von Nachrichten dieses Typs. 
[0053] Das Beispiel von Fig. 4 zeigt eine Filterinitiali- 

55 sierungsanforderung 401 , welche von einem Kommuni- 
kationsendgerat MS an einen Transaktionsserver WS 
gesendet wird. Urn eine Umleitung einer Zahlungsan- 
forderung 300, die fur das Kommunikationsendgerat 
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MS bestimmt ist, von dem Filter Fl an den Transaktions- 
server WS zu ermoglichen, sendet der Transaktionsser- 
ver WS dem Filter Fl seine Adresse mittels einer Filter- 
initialisierungsnachricht 402 zu. 
[0054] In weiteren Ausgestaltungen der Erfindung re- 
prasentieren die in den Figuren 3 und 4 dargestellten 
Nachrichten jeweils ein Nachrichtenbundel, welches 
Nachrichten zur Bestatigung, Authentifizierung oder 
Verschlusselung umfassen kann. 
[0055] Eine weitere Ausgestaltung der vorliegenden 
Erfindung betrifft ein Computerprogramm. Das Compu- 
terprogramm, welches in einen internen Speicher einer 
digitalen Rechnereinheit, insbesondere eines Kommu- 
nikationsendgerates, geladen werden kann, enthalt 
Softwarecodeteile, die geeignetsind, das erfindungsge- 
mal3e Verfahren durchzufuhren, wenn das Computer- 
programm auf der Rechnereinheit ausgefuhrt wird. 
[0056] Dieses Computerprogramm kann insbesonde- 
re auch auf einem computerlesbaren Medium wie bei- 
spielsweise einer Diskette, CD-ROM oder einer opti- 
schen Platte gespeichert sein. 



Patentanspruche 

1 . Verfahren zur Einleitung einer elektronischen Zah- 
lungstransaktion mit folgenden Schritten: 

Empfangen einer Zahlungsanforderung (300) 
durch einen Filter (Fl) eines Kommunikations- 
systems, 

- Modifizieren der Zahlungsanforderung (300) 
durch Hinzufugen einer Transaktionskenn- 
zeichnung, 

Obertragen der modifizierten Zahlungsanfor- 
derung (301) an einen Transaktionsserver 
(WS), 

Obertragen einer Zahlungsanforderungsinfor- 
mation (302), welche die Transaktionskenn- 
zeichnung enthalt, von dem Filter (Fl) an ein 
Kommunikationsendgerat (MS), 
Obertragen einer Zahlungsinitialisierung (303), 
welche eine weitere Transaktionskennzeich- 
nung enthalt, von dem Kommunikationsendge- 
rat (MS) an den Transaktionsserver (WS), 

- Vergleichen der Transaktionskennzeichnun- 
gen der modifizierten Zahlungsanforderung 
(301) und der Zahlungsinitialisierung (303) 
durch den Transaktionsserver (WS), 
Durchfuhren der Zahlungstransaktion (304) 
durch den Transaktionsserver (WS), wenn die 
Transaktionskennzeichnungen ubereinstim- 
men. 

2. Verfahren nach Anspruch 1 , bei welchem die Trans- 
aktionskennzeichnung eine Zufallszahl ist. 

3. Verfahren nach Anspruch 1 oder 2, bei welchem die 



Zahlungsanforderung (300) fur das Kommunikati- 
onsendgerat (MS) bestimmt ist und von dem Filter 
(Fl) mittels eines ersten Bezeichners erkannt und 
abgefangen wird. 

5 

4. Verfahren nach Anspruch 1 , 2 oder 3, 

bei welchem der Filter (Fl) eine Filterinitialisie- 
rungsnachricht (402), die eine Adresse des 
10 Transaktionsservers (WS) enthalt, empfangt 

und speichert, 

und bei welchem der Filter (Fl) die modifizierte 
Zahlungsanforderung (301 ) mittels der gespei- 
cherten Adresse sendet. 

15 

5. Verfahren nach Anspruch 4, bei dem der Filter (Fl) 
die Filterinitialisierungsnachricht (402) mittels eines 
zweiten Bezeichners erkennt und abfangt. 

20 6, Verfahren nach einem der Anspruche 1 bis 5, bei 
dem der Transaktionsserver (WS) nach Empfang 
einer Filterinitialisierungsanforderung (401) die Fil- 
terinitialisierungsnachricht (402) sendet. 

25 7. Verfahren zur Initialisierung eines Filters (Fl) eines 
Kommunikationssystems, bei dem ein Transakti- 
onsserver (WS) eine Filterinitialisierungsanforde- 
rung (401) empfangt, 

30 bei dem der Transaktionsserver (WS) eine Fil- 

terinitialisierungsnachricht (402) mit einer 
Adresse, die den Transaktionsserver (WS) be- 
zeichnet, sendet, 

und bei dem der Filter (Fl) die Filterinitialisie- 
35 rungsnachricht (402) empfangt und die Adres- 

se speichert. 

8. Verfahren nach Anspruch 7, bei dem der Filter (Fl) 
die Filterinitialisierungsnachricht(402) mittels eines 

to Bezeichners erkennt und abfangt. 

9. Filter fur ein Kommunikationssystem, mit 

- einer Eingangsschnittstelle zum Empfang einer 
45 Zahlungsanforderung (300), 

einer Rechnereinheit zur Identifizierung der 
Zahlungsanforderung (300) und zur Modifikati- 
on durch Hinzufugen einer Transaktionskenn- 
zeichnung, 

50 - einer Ausgangsschnittstelle zum Senden der 
modifizierten Zahlungsanforderung (301 ) an ei- 
nen Transaktionsserver (WS), sowie zum Sen- 
den einer Zahlungsanforderungsinformation 
(302), welche die Transaktionskennzeichnung 

55 enthalt, an ein Kommunikationsendgerat (MS). 

10. Filter nach Anspruch 9, mit einem Zufallszahlenge- 
nerator, welcher als die Transaktionskennzeich- 
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nung eine Zufallszahl ermittelt. 

11. Filter nach Anspruch 9 Oder 10, bei welchem die 
Rechnereinheit das Vorhandensein eines ersten 
Bezeichners in der Zahlungsanforderung (300) 5 
uberpruft und die Zahlungsaufforderung (300) ab- 
fangt. 

12. Filter nach Anspruch 9, 10 Oder 11, welcher eine 
Filterinitialisierungsnachricht (402), die eine Adres- 
se des Transaktionsservers (WS) enthalt, uber die 
Eingangsschnittstelle empfangt und in einem Spei- 
cher speichert, und bei welcher die modifizierte 
Zahlungsanforderung (301 ) mittels der gespeicher- 
ten Adresse sendet. 

13. Filter nach einem der Anspruche 9 bis 12, welcher 
die Filterinitialisierungsnachricht (402) mittels eines 
zweiten Bezeichners erkennt und abfangt. 

20 

14. Transaktionsserver, mit 

- einer Eingangsschnittstelle zum Empfang einer 
modifizierten Zahlungsanforderung (301) mit 
einer ersten Transaktionskennzeichnung und 25 
zum Empfang einer Zahlungsinitialisierung 
(303) mit einer zweiten Transaktionskenn- 
zeichnung, 

einer Recheneinheit zum Vergleichen der 
Transaktionskennzeichnungen der modifizier- 30 
ten Zahlungsanforderung (301) und der Zah- 
lungsinitialisierung (303), und mit 
einer Ausgabeschnittstelle, uber welche die 
Recheneinheit eine Zahlungstransaktion (304) 
durchfuhrt, wenn die Transaktionskennzeich- 35 
nungen iibereinstimmen. 

15. Transaktionsserver (WS) nach Anspruch 14, wel- 
cher nach einem Empfang einer Filterinitialisie- 
rungsanforderung (401) eine Filterinitialisierungs- *o 
nachricht (402) sendet. 

16. Computerprogramm, welches in einen internen 
Speicher einer digitalen Rechnereinheit geladen 
werden kann, und welches Softwarecodeteile ent- 
halt, die geeignet sind, die Schritte nach einem der 
Anspruche 1 bis 8 durchzufuhren, wenn das Com- 
puterprogramm auf der Rechnereinheit ausgefuhrt 
wird. 

17. Computerprogramm nach Anspruch 16, bei dem 
das Computerprogramm auf einem computerlesba- 
ren Medium gespeichert ist. 
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13 



THIS PAGE BLANK (usptoj 

THIS ^hol Du-uvrx ^uon^ 



